Capability-based security
gpt-5.icon
**Capability-based security（ケイパビリティ指向セキュリティ）**は、
「誰か（主体）が何であるか」ではなく「その主体がどの操作を実行できるか」を明示的な capability（権能・権限オブジェクト）として扱うアクセス制御モデル。
1. 基本概念
Capability とは
以下を不可分なトークンとしてまとめたもの。
対象（object）: ファイル、メモリ領域、API、サービスなど
操作（rights）: read / write / execute / invoke など
真正性: 偽造できないこと（カーネル管理、暗号署名など）
「この capability を持っているなら、この操作ができる」
2. 従来モデルとの対比
主体（user / role）→ 対象（resource）への許可表
例:
Alice は fileA を read できる
Capability-based（権限中心）
主体は capability を所持しているかどうかのみが重要
例:
この read(fileA) capability を持つプロセスは read できる
table:_
観点 ACL / RBAC Capability-based
基準 Who you are What you have
権限管理 集中管理 分散（トークン所持）
最小権限 設計次第 自然に実現しやすい
委譲 面倒 非常に簡単
3. 重要な性質
capability は必要最小限の操作だけを含む
誤用・侵害時の影響範囲が小さい
② 明示的な権限委譲
capability を他者に渡す＝権限委譲
ACL のような再設定不要
code:text
Process A ──(capability)──▶ Process B
グローバル権限（「root だから何でもできる」）を避ける
権限は参照として渡されるものだけ
4. 実装レイヤ別の例
OS / カーネル
ファイルディスクリプタも一種の capability
open() で得た fd を持つプロセスだけが操作可能
プログラミング言語
グローバル変数・静的アクセスを制限
code:js
function makeLogger(fileCap) {
return () => fileCap.write("log");
}
Web / 分散システム
Bearer Token / OAuth Access Token
Signed URL (S3 presigned URL)
URL を知っているだけで操作できる → capability 的
5. 現代的な具体例
URL = capability
含まれる権限:
対象: bucket/object
操作: GET / PUT
制限: 有効期限
Kubernetes
ServiceAccount Token + RBAC
→ capability 風だが、完全な capability ではない（主体依存）
6. メリット・デメリット
メリット
セキュリティ境界が明確
権限の委譲・分割が容易
分散システムと相性が良い
デメリット
Capability の漏洩 = 権限漏洩
revoke（失効）が難しい
対策: 有効期限 / indirection / versioning
設計思想の理解コストが高い
実装してる例
これはプログラミング言語
capcabilityのコピーを防止する